Practical Byzantine Fault Tolerance (PBFT) is a type of consensus mechanism that can be implemented in distributed systems such as blockchain systems. PBFT consensus mechanism enables a distributed system to reach a sufficient consensus with safety and liveness, despite that certain nodes of the system may fail (e.g., due to poor network connection or otherwise becomes faulty) or propagate incorrect information to other peers (e.g., acting maliciously). The objective of such mechanism is to defend against catastrophic system failures by mitigating the influence of the non-functioning nodes on the correct function of the system and on the consensus reached by the functioning nodes (e.g., non-faulty and honest nodes) in the system.
The PBFT consensus mechanism focuses on providing a practical Byzantine state machine replication that tolerates Byzantine faults (e.g., non-functioning nodes) through an assumption that there are independent node failures and manipulated messages propagated by specific and independent nodes. In this PBFT consensus mechanism, for example, all nodes in a blockchain system are ordered in a sequence with one node being the primary node (also known as the leader or master node) and the others referred to as the backup nodes (also known as follower nodes). All of the nodes within the system communicate with each other, and the goal is for all honest nodes to come to an agreement/consensus on a state of the system.
For instance, for the PBFT consensus mechanism to work, the assumption is that the amount of non-functioning nodes in a blockchain system cannot simultaneously equal or exceed one third of the overall nodes in the system in a given window of vulnerability. The method effectively provides both liveness and safety as long as at most F nodes are non-functioning nodes at the same time. In other words, in some implementations, the number F of non-functioning nodes that can be tolerated by the PBFT consensus mechanism equals (N−1)/3, rounded down to the nearest integer, wherein N designates the total number of nodes in the system. In some implementations, a blockchain system implementing the PBFT consensus mechanism can handle up to F Byzantine faults where there are at least 3F+1 nodes in total.
The PBFT consensus mechanism may generally comprise a normal operation protocol (also known as the triple-stage protocol) and a view change protocol, wherein the normal operation protocol is provided for ensuring the safety of the mechanism, while the view change protocol is provided for ensuring the liveness of the mechanism. The normal operation protocol mainly includes three phases in order, i.e., a Pre-prepare phase, a Prepare phase, and a Commit phase. All phases are message-driven, i.e., a next phase in the protocol is triggered by obtaining a sufficient number of messages in a current phase.
During the normal operation protocol, the view change protocol may be triggered if the current primary node becomes non-functioning in order to elect a new primary node based on consensus. By replacing the current primary node, the normal operation protocol can be resumed to execute the functions of the system. However, for the view change protocol to trigger, the current primary node has to show “non-functioning” behaviors, such as abandoning transactions (when the PBFT consensus mechanism is used for verifying blockchain transactions), manipulating transactions, falsifying transactions, etc. These behaviors may be complicated and easy to overlook, when the system tries to compile them into a set of triggering rules. Moreover, the view change protocol also carries a high communication cost. To effectuate the current primary node replacement through view change, an amount of communication volume on a scale of O(N2) is required, where N blockchain nodes each need to send N messages (e.g., view change messages, new-view messages, etc.) to peer blockchain nodes. Further, multiple rounds of the view change protocol may need to be executed to change the current primary node, which causes instability and disruption to the normal function of the system. Therefore, it is desirable to provide an alternative solution to effectuate current primary node change without the complicated configuration and communication burden.